This invention relates to transmission of information between multiple digital devices on a network. More particularly, this invention relates to a method and apparatus for automatically updating and distributing executable files and components via a network in a distributed fashion.
Related technology is discussed in co-assigned co-pending U.S. patent applications Ser. Nos. 08/506,533, entitled METHOD AND APPARATUS FOR ASYNCHRONOUS PPP AND SYNCHRONOUS PPP CONVERSION, filed Jul. 25, 1995; 08/502,835 entitled VIRTUAL NETWORKING ARCHITECTURE filed Jul. 14, 1995, and 08/542,157, entitled METHOD AND APPARATUS FOR TRANSPARENT INTERMEDIATE SYSTEM BASED FILTERING ON A LAN OF MULTICAST PACKETS, filed Oct. 12, 1995 and incorporated herein by reference to the extent necessary to understand the invention.
Networking Devices Standards
This specification presumes some familiarity with the general concepts, protocols, and devices currently used in LAN networking applications and in WAN internetworking applications. These standards are publicly available and discussed in more detail in the above referenced and other co-assigned patent applications.
This specification also presumes some familiarity with the specific network and operating system components discussed briefly in the following paragraphs, such as the simple network management protocol (SNMP) for management of LAN and WAN networks, and the RMON MIBs defined for remote network monitoring and management.
General Network Topology
FIG. 1 illustrates a local area network (LAN) 40 of a type that might be used today in a moderate sized enterprise as an example of a network in which the present invention may be deployed. LANs are arrangements of various hardware and software elements that operate together to allow a number of digital devices to exchange data within the LAN and also may include internet connections to external wide area networks (WANs) such as WANs 42 and 44. Typical modern LANs such as 40 are comprised of one to many LAN intermediate systems such as 60-63 that are responsible for data transmission throughout the LAN and a number of end systems (ESs) such as ESs 50a-d, 51a-c, and 52a-g, that represent the end user equipment. The ESs may be familiar end-user data processing equipment such as personal computers, workstations, and printers and additionally may be digital devices such as digital telephones or real-time video displays. Different types of ESs can operate together on the same LAN. In one type of LAN, LAN intermediate systems 60-63 are referred to as bridges or switches or hubs and WAN ISs 64 and 66 are referred to as routers, however many different LAN configurations are possible, and the invention is not limited in application to the network shown in FIG. 1.
Packets
In a LAN such as 40, data is generally transmitted between ESs as independent packets, with each packet containing a header having at least a destination address specifying an ultimate destination and generally also having a source address and other transmission information such as transmission priority. Packets are generally formatted according to a particular protocol and contain a protocol identifier of that protocol. Packets may be encased in other packets. FIG. 2 illustrates a packet 200. Packet 200 is essentially an Ethernet packet, having an Ethernet header 202 and a 48-bit Ethernet address (such as 00:85:8C:13:AA) 204, and an Ethernet trailer 230. Within the Ethernet packet 200 is contained, or encapsulated, an ASU protocol packet, represented by ASU header 212, containing a 32 bit ASU address 214 (such as 199.22.120.33). Packet 200 contains a data payload 218 which holds the data the user is interested in receiving or holds a control message used for configuring the network.
Layers
Modern communication standards, such as the TCP/IP Suite and the IEEE 802 standards, organize the tasks necessary for data communication into layers. At different layers, data is viewed and organized differently, different protocols are followed, different packets are defined and different physical devices and software modules handle the data traffic. FIG. 3 illustrates one example of a layered network standard having a number of layers, which we will refer to herein as: the Physical Layer, the Data Link Layer, the Routing Layer, the Transport Layer, the Session Layer, the Presentation Layer and the Application Layer. These layers correspond roughly to the layers as defined within the TCP/IP Suite. (The 802 standard and other standards have different organizational structures for the layers.)
Generally, when an ES is communicating over a network using a layered protocol, a different software module may be running on the ES at each of the different layers in order to handle network functions at that layer. Examples of software modules existing within an ES at different layers are shown in FIG. 3.
Drivers and Adapters
Each of the ISs and ESs in FIG. 1 includes one or more adapters and a set of drivers. An adaptor generally includes circuitry and connectors for communication over a segment and translates data from the digital form used by the computer circuitry in the IS or ES into a form that may be transmitted over the segment, which may be electrical signals, optical signals, radio waves, etc. A driver is a set of instructions resident on a device that allows the device to accomplish various tasks as defined by different network protocols. Drivers are generally software programs stored on the ISs or ESs in a manner that allows the drivers to be modified without modifying the IS or ES hardware.
NIC Driver
The lowest layer adaptor software operating in one type of network ES is generally referred to as a NIC (Network Interface Card) driver. A NIC driver is layer 2 software designed to be tightly coupled to and integrated with the adaptor hardware at the adaptor interface (layer 1) and is also designed to provide a standardized interface between layer 2 and 3. Ideally, NIC drivers are small and are designed so that even in an ES with a large amount of installed network software, new adaptor hardware can be substituted with a new NIC driver, and all other ES software can continue to access the network without modification.
NIC drivers communicate through one of several available NIC driver interfaces to higher layer network protocols. Examples of NIC driver interface specifications are NDIS (Network Driver Interface Specification developed by Microsoft and 3Com) and ODI (Open Data-Link Interface developed by Apple Computer and Novell).
Generally, when an ES is booting up and begins building its stack of network protocol software, the NIC driver loads first and tends to be more robust than other network software modules because of its limited functions and because it is tightly designed to work with a particular hardware adaptor.
Management and Monitoring of Individual ESs in a Network Environment
A network such as that shown in FIG. 1 is generally managed and monitored within an enterprise by a central Information Services department (ISD), which is responsible for handling all the interconnections and devices shown. The same ISD is generally responsible for managing the applications and system components on each of the individual ESs in the network.
Many prior art systems have been proposed to allow an IS staff person to manage and monitor network infrastructure remotely over a network. Such systems include Intel's LAN-desk, IBM's NetView, HP's OpenView, Norton Administrator, McAfee's ZAC or Novell's Network Management System (NMS). However, these systems generally rely on a full network protocol stack to be correctly running effectively on the remote ES in order to accomplish any remote file management operations. Often, however, ES system trouble or software updates results in one or more network protocol functions becoming non-operational. Under most prior art remote management systems, if any part of the remote ES network protocol stack is not working, the IS manager cannot access an ES through the network and must physically travel to the remote location to fix or diagnose the problem. Also, ISD management becomes extremely expensive in terms of ISD's keeping track of numerous different software modules on sometimes thousands of systems and of installing new versions or minor fixes of software on each system. It has therefore long been a desire of ISD managers and the owners of large numbers of ESs connected on a network to be able to automatically update software components over the network. Such updating ideally would be capable of updating both application software components, system software components, and even network components while the network is running. Such a system should also be able to automatically track version numbers of software in ESs and determine when update components must be downloaded.
Simple Network Management Protocol (SNMP)
A common protocol used for managing network infrastructure over the network is the Simple Network Management Protocol (SNMP). SNMP is a layer 7 network and system management protocol that handles network and system management functions and can be implemented as a driver (or SNMP agent) interfacing through UDP or some other layer 4 protocol. Prior art SNMP installations largely were not placed in ESs because SNMP did not handle ES management or monitoring functions and because SNMP agents are processor and memory intensive.
SNMP is designed to provide a simple but powerful cross platform protocol for communicating complex data structures important to network infrastructure management. However, its power and platform-independent design makes it computationally intensive to implement, and for that reason it has limited applications in end system management or monitoring. It is primarily used in network infrastructure management, such as management of network routers and bridges.
SNMP is designed to support the exchange of Management Information Base (MIB) objects through use of two simple verbs, get and set. MIB objects can be control structures, such as a retry counter in an adaptor. Get can get the current value of the MIB and set can change it. While the SNMP protocol is simple, the MIB definitions can be difficult to implement because MIB ids use complex data structures which create cross-platform complexities. SNMP has to translate these complex MIB definitions into ASN.1 which is a cross-platform language.
Even if installed in an ES, an SNMP agent cannot be used to manage or diagnose an ES or update system components where the UDP protocol stack is not working properly, which will often be the case when the network connection is failing. When working, SNMP provides a protocol interface for higher layer prior art management applications.
SNMP is described in detail in a number of standard reference works. The wide adoption of SNMP throughout the networking industry has made compatibility with SNMP an important aspect of new management and monitoring tools.
Prior Art Update Systems
Prior art systems such as Intel's LAN-desk, and others, allow for the installation and updating of applications remotely. However, those systems are limited to updating application level software components. Also, these systems are limited to using network and higher layer protocols, such as IP and IPX, that can be rendered unusable by seemingly innocuous configuration problems and which therefore become unreachable, remotely. Additionally, the higher layer protocols result in a burdensome use of the network as they generate more control packets relative to the number of packets carrying data than do lower level protocols such as layer 2 protocols. This prevents servers from living in resource limited devices, such as switches, for example. Further, the higher level protocols require a larger application running on an end system (ES), which requires greater system resources.
Prior art systems, such as Intel's LAN-desk, use a "push" technology for updating that forces updating at the end system, and which requires large database management resources to keep track of update statistics such as which end-station received which update, and which end-station still needs to be updated with which components, for example.
Login scripts are used in many prior art systems. Login scripts are executed each time a user logs into the network at an end-system (ES), for example. Login scripts can execute programs at the server, such as programs that inventory component versions running at the ES and that update the ES by "pushing" down components where needed. However, systems using login scripts lack the ability to dynamically update components that are actually running at the ES.
What is needed in the art is a system for automatically installing and updating system level software components (OS), in addition to applications and agent software components, using an improved data link control protocol that requires fewer network resources than conventional protocols and which is less burdensome on network traffic. Also needed in the art is the ability to "pull" components down from a server (i.e., to update software remotely and automatically without requiring that agents automatically receive and load the newest versions of all software now available, but with the ability to support "push" technology if necessary).
For purposes of clarity, the present discussion refers to network devices and concepts in terms of specific examples. However, the method and apparatus of the present invention may operate with a wide variety of types of network devices including networks dramatically different from the specific examples illustrated in FIG. 1 and described below. It is therefore not intended that the invention be limited except as done so in the attached claims.